A Public Warning System (PWS), which is a system for warning disasters and other emergencies, is able to publish warning messages to users timely and accurately when a disaster, such as an earthquake, a tsunami, a hurricane, and a wildfire, is encountered, so that the users can take appropriate actions to protect themselves and their families from serious injuries or deaths or avoid serious property loss. A PWS defined in the 3rd Generation Partnership Project (3GPP) can be applied in different communication systems, such as a Global System of Mobile communication (GSM), a Universal Mobile Telecommunication System (UMTS) and a Long Term Evolution (LTE) communication system. The PWS includes an Earthquake and Tsunami Warning System (ETWS), a Commercial Mobile Alert System (CMAS) and an Emergency Alert System (EAS).
FIG. 1 shows a basic network architecture of a PWS in an Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN) of LTE (FIG. 1 is a schematic diagram of a network architecture of a PWS in an E-UTRAN according to a related technology). In the network architecture, a Cell Broadcast Entity (CBE), which does not belong to a communication network defined by the 3GPP, is mainly responsible for formatting Cell Broadcast Service (CBS) messages; a Cell Broadcast Center (CBC), which is a part of a core network, is responsible for managing CBS messages, including: distribution of a Serial Number, and modification and deletion of a CBS message of an evolved Node B (eNB), determination of a cell to which a CBS message is broadcast, determination of time when a CBS message starts to be broadcast, determination of time when the CBS message stops being broadcast, and determination of a broadcast period of a CBS message and so on. Besides general functions, a Mobility Management Entity (MME) is also responsible for explaining a command from the CBC, storing a message from the CBC, returning an acknowledgement to the CBC after successfully executing the command received from the CBC, reporting a failure to the CBC when the command received from the CBC is not understood or not executed, and routing a warning message to an appropriate eNB in an indicated Tracking Area (TA). An eNB is mainly responsible for broadcasting the warning message received from the MME to User Equipment (UE) residing in a related area to which the eNB belongs. The CBC may be coupled with a plurality of MMEs, and may also be coupled with a plurality of CBEs. The CBC is coupled with an MME through a SBc interface. The MME is coupled with the eNB through an S1-MME interface. The eNB is coupled with the UE through a Uu port. An interface between the CBE and the CBC is not specified in 3GPP standards.
FIG. 2 is a flowchart of transmitting a warning message in an E-UTRAN in a related technology. As shown in FIG. 2, the flow includes the following steps.
Step S200: A network registration and security procedure is executed. An UE stores a flag for indicating whether authentication to the network is required. This step is executed each time when the UE is attached to the network.
Step S201: A CBE sends emergency information, such as a “warning type”, a “warning message”, an “impacted area”, or a “time period”, to a CBC, and the CBC authenticates the request.
Step S202: By using information of the “impacted area”, the CBC identifies MMEs to which a warning message needs to be sent. The CBC sends a Write-Replace Warning Request message to these MMEs, wherein the Write-Replace Warning Request message includes a broadcast warning message and transmission attributes (the transmission attributes including a Message Identifier, a Serial Number, a Tracking Area ID list (used in the MME only and used by the MME to select eNBs to which the Write-Replace Warning Request message is sent), a warning area (which is a cell identifier list, or a Tracking Area identifier list or one or more emergency area identifiers), and a Send Write-Replace-Warning-Indication (which needs to be set by the CBC when the CBC requires the MME to send a Write-Replace Warning Indication message including a Broadcast Scheduled Area List Information Element (IE)).
Step S203: The MME sends a Write-Replace Warning Confirm message to the CBC to indicate that the MME has started allocating the warning message to the eNBs. The Write-Replace Warning Confirm message may include an Unknown Tracking Area List IE indicating Tracking Areas which are unknown to the MME and to which the request cannot be sent.
Step S204: Upon receiving the Write-Replace Warning Confirm message from the MME, the CBC may send an Emergency Broadcast Response message to the CBE to acknowledge that publishing of the warning message has been started.
Step S205: The MME forwards the Write-Replace Warning Request message to the eNBs, and uses the Tracking Area ID list to determine the eNBs for transmitting the warning message.
Step S206: When there is an S1-flex at the eNB so that the eNB can receive the same warning message from a plurality of MMEs, the eNB may discover a repeated message by verifying Message Identifiers and Serial Numbers in warning messages. Only the first received message will be broadcast by a cell if a redundant message is discovered. The eNB uses warning area information to decide cells to which the warning message is broadcast. The eNB returns a Distribute Warning Message Response message to the MME.
Step S207: If the UE has been configured to receive the warning message and has been authenticated by a core network, the UE will use a value of the “warning type” (an “earthquake”, a “tsunami”, or an “earthquake and tsunami”) to warn a user immediately.
Step S208: If the Send Warning-Message-Indication parameter is included in the Write-Replace Warning Request sent by the CBC to the MME, the MME needs to include Broadcast Scheduled Area Lists in the Write-Replace Warning Indication message sent to the CBC, wherein the Broadcast Scheduled Area Lists includes: contents in Broadcast Completed Area Lists received by the MME from eNBs. The MME may combine the Broadcast Completed Area Lists received from the eNBs.
Step S209: The MME decides whether transmission of the warning message succeeds or fails, and creates a tracking report.
FIG. 3 is a flowchart of cancelling a warning message in an E-UTRAN in a related technology. A shown in FIG. 3, the flow includes the following steps.
Step S301: A CBE sends a Stop Emergency Broadcast Request message to a CBC, wherein the message includes: a Message Identifier and a Serial Number.
Step S302: The CBC identifies MMEs to which a stop warning message needs to be sent. The CBC sends a Stop Write-Replace Warning Request message to these MMEs, wherein the Stop Write-Replace Warning Request message includes a Message Identifier, a Serial Number, a Tracking Area ID list and a warning area.
Step S303: The MMEs send a Stop Warning Confirm message, wherein the message is used for notifying the CBC that the MMEs have started allocating a Kill Request message to eNBs.
Step S304: After receiving the Stop Warning Confirm message from the MMEs, the CBC may send a Stop Emergency Broadcast Response message to the CBE to acknowledge that a warning message cancelling process has been initialized.
Step S305: The MMEs send the Kill Request message to the eNBs, in the process, the MMEs may use the Tracking Area ID list to decide the eNBs that are broadcasting a warning message.
Step S306: Each eNB stops a warning message which is identified by a Message Identifier and a Serial Number and being broadcast in an area identified by a Warning Area ID, and returns a Kill Response message to the MME.
Step S307: The MMEs create a tracking record about cancelling the message.
At present, a broadcast state of a warning message at a network side needs to be reported in the following scenarios: (1) As required by the Netherlands Government on NL-Alert, the Netherlands Government needs to know a network state and whether an NL-Alert message is published successfully; (2) A CBC considers that a broadcast message has been cancelled and references (a Message Identifier and a Serial Number) of the warning message have been deleted, however, cancellation at the network side fails due to an unknown reason, which will result in inconsistency of states at the network side and the CBC side, and an operator may require reporting the state at the network side. Nevertheless, until now, the related technology has by no means provided a method capable of reporting a broadcast state of a warning message by a network side.
Currently, there is no effective solution yet for the problem that a method for reporting a broadcast state of a warning message by a network side is not provided by a related technology.